iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 3
0

本文同步刊登於個人技術部落格,有興趣關注更多 Kubernetes、DevOps 相關資源的讀者,請務必追蹤從零開始的軟體工程師之旅,喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論,技術方面諮詢免錢、需要動手做另計 XD。

曬貓


Borg, Omega and Kubernetes

這是原文完整版本。好讀版請見 Borg Omega and Kubernetes 前世今生摘要

完整英文原文請見 Borg, Omega, and Kubernetes - Lessons learned from three containermanagement systems over a decade


容器 (Containers)

回顧歷史,第一個容器只提供 root file system (透過 chroot)。

  • FreeBSD jail 進一步延伸出額外的命名空間 (namespace) 例如 process ID。
  • Solaris 大幅地探索相關的新功能。
  • Linux control groups (cgroups) 吸收這些想法,直到今日仍持續開發。

容器提供資源隔離 (resource isolation),Google 得以大幅提升資源使用率 (utilization) 超出當時產業平均值,例如

  • Borg 使用容器,將批次暫時工作、與面對用戶需要注意延遲的應用,兩者放在同樣的物理機器上。
  • 用戶應用需要預留更多額外的資源,來處理突然產生的負載高峰 (load spikes) 以及錯誤處理 (fail-over) ,
  • 這些預留的資源常常都不會用到,可以轉讓批次工作使用。

容器提供的資源管理工具實現此類需求,kernel-level 的資源隔離也確保程序之間不會互相干擾。Google 開發 Borg 中,同時也提交新功能給 Linux 容器,來滿足上述的需求。

然而目前的隔離並不完整,如果 Linux kernel 不管理的資源,容器自然也無法隔離,例如

  • level-3 的處理器快取 (level-3 processor cache) 與
  • 記憶體帶寬 (memory bandwith),
  • 容器還需要增加一層安全保護層 (例如虛擬機器 Virtual Machine) 才能對付公有雲上出現的惡意行為。

現代的容器不只提供隔離機制,更提供映像檔 (image),在這個檔案上建構容器的應用。Google 使用 Midas Package Manager (MPM) 來建構並部屬容器映像檔,隔離機制與 MPM package 的關係,可以對比 Docker daemon 與 Docker image registry。這個章節描述的「容器」同時包含兩個概念:隔離、映像檔。

應用導向的架構 (Application-oriented infrastructure)

隨著時間證明,容器不只能提供高階的資源使用率,容器化 (containerization) 使資料中心 (data center) 從原本機器導向 (machine-oriented) 變成應用導向 (application-oriented),這個段落提供兩個例子:

  • 容器封裝 (encapsulate) 應用的環境 (environment),在機器與作業系統的細節上,增加一層抽象層,解藕兩件事情:應用開發、部屬到架構。
  • 良好設計的容器與映像檔只專注在單一個應用,管理容器意味管理應用,而不是管理機器。這點差異使得管理的 API,從機器導向變成影用導向,大幅度的改善應用的部屬與監控。

應用的環境 (Application environment)

  • 原本 kernel 內的 cgroup、chroot、與命名空間,是用來保護應用不被旁邊其他應用的雜訊影響。
  • 將這些工具與容器映像檔一起使用,產生一層抽象層,分離應用、與底下的 (各種不同家的) 作業系統。
  • 解藕映像檔與作業系統,進一步提供相同的環境給開發環境 (development) 與生產環境 (production),降低環境間的不一致性造成的問題,最終提升開發的可靠程度、並加速開發的流程。

建構這層抽象的關鍵是,使用密閉的容器映象檔 (hermetic container image) ,將所有應用有關的依賴 (dependencies) 都打包,整包部屬到容器中。

  • 正確執行的話,容器對外部的依賴只剩下 Linux kernel 系統調用介面 (system-call interface)。
  • 這層介面大幅改善映象檔的部屬方便性 (protability),但目前機制仍不完美,應用仍然暴露在某些作業系統的介面上,特別是
    • socket options、
    • /proc、以及
    • ioctl 的調用參數。

Google 希望透過推廣開放容器倡議 (Open Container Initiative) 來清楚界定,上述介面與容器的抽象層。

次外,容器提供的隔離與最小依賴,在 Google 證明非常有效,容器是 Google 架構上唯一的可執行單位 (runnable entity),進一步使 Google 只提供少數的作業系統版本給所有機器,只需要少數的維護人員來負責管理版本。

密閉容器映想檔有很多方式達成,

  • 在 Borg 建構映想檔時,應用的執行檔 (binary) 靜態連結到可用的程序庫 (library) 版本,程式庫在公司內部存放。
  • 至此 Borg 容器映像檔還不是完全密閉,底下還有依賴一層基底映象檔 (base image),直接事先安裝到機器上,而不是隨映像檔部屬,
  • 基底映象檔包含通用工具例如 tar 與 libc 程式庫,因此更新基底映象檔仍會影響應用,偶爾會產生大麻煩。

現代的容器映像檔格式,如 Docker 與 ACI,都加強這層抽象、提供更緊密的封裝,移除特定作業系統的依賴性,並要求使用者在分享映象檔內容時,必須明確宣告。


今天只是講古,知道 Kubernetes 的前世今生。文章重點在後面 XD

明日待續:容器作為管理單位 (Container as the unit of management),資料中心的轉型


上一篇
Day 2 - Borg Omega and Kubernetes,Kubernetes 的前日今生,與 Google 十餘年的容器化技術
下一篇
Day 4 - Borg Omega and Kubernetes, 容器作為管理單位 (Container as the unit of management)
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言